Information View
Introduction
As a build automation tool, Gradle strives to be both performant and flexible. Gradle's build cache is used to achieve its performance goals. Similarly, Gradle's configuration objects and script files are designed to be flexible automation tools.
| Content | Description |
|---|---|
| Build Cache | This section descibes how Gradle uses the cache to meet its performance goals, the run-time cache implementation behavior and the cache storage solution. |
| Configuration Object | This section describes how Gradle meets its flexibility by using run-time configuration objects, how those objects are loaded from persistent configuration data and how those objects relate to each other. |
Build Cache
We identify Gradle's caching mechanism as a key architectural element which contributes greatly to Gradle's performance. We will describe the purpose of Gradle's cache, its usage, cached information integrity mechanisms and data retention policies.
The inclusion of the build cache section is motivated partially by important scenario 3. Gradle's incremental builds use the build cache. Therefore, we believe that this section will convince readers that Gradle possesses the required tools to perform incremental builds.
Purpose & Usage
One of Gradle's quality properties is performance. Gradle's build cache, improves performance by storing previously computed information such that subsequent Gradle builds need not perform redundant work. Caching is an application of the reuse of resources and results architectural tactic.
To improve performance, Gradle utilizes the cache by executing incremental builds and skipping the loading phase phase for some configuation objects during the configuration lifecycle phase.
Cache Implementation
Tasks which are tagged as cacheable will have their output stored in the cache storage following a successful execution. A task which produces reproducible results (if the same input is given, then the same output is produced) can be tagged as cacheable.
Therefore, instead of executing cacheable tasks, the cached outputs may be retrieved through a simple key-value pair lookup. The key would be the task's input (or its hash).
When looking for cached entitites, Gradle will first search the local cache followed by the remote cache. This maximizes performance by minimizing network transfer overhead
Gradle uses a a simple locking mechanism as as evidenced by the code to prevent concurrent read and write access to the cache. The integrity of the cache is maintained by removing corrupt cached files.
Storage
The caching feature allows for cache to be stored both locally and remotely. However, Gradle's default caching solution is a simple local directory build cache. Each cached file has a build cache key which may maps to a file.
Information retention policies may be set to remove unused cached files after a given period of time. These policies are used to save storage space and can be configured by the user.
Configuration Object Definition Model
The configuration object definition model is used to demonstrate how Gradle can be configured through the use of user-defined files/ code.
Configuration Objects
Configuration objects are run-time object instances whose state determines the behavior of a given Gradle execution. The configuration object definition model demonstrates the mapping between architecturally significant run-time configuration objects and the persistent data from which they loaded. ArtifactRepository configuration objects are not included in the model due to the ambiguous nature of their defining data source.
As mentioned in the build cache section, configuration objects can be fetched from the cache rather than loaded from their defining data source.
Configuration objects are initialized during the Gradle's configuration lifecycle phase (orthe initialization phase for Settings). Their configuartion dictates the behavior during the execution phase.
Data Source
build.gradle
The build.gradle file has a 1-1 mapping with a project configuration object. The content of the file is written in either Groovy or Kotlin. The file is used to configure and add tasks to a project configuration object.
gradle.properties
The gradle properties file is a simple key value store used to configure build variables. The file may appear multiple times especially in a multi-project setup. The properties file is not required by all Gradle executions. The properties file may be used to set both general or project specific properties.
settings.gradle
A gradle execution loads a single settings.gradle file. During the initialization lifecycle phase the settings.gradle file is loaded into a Settings configurations object. The settings object contains all the necessary information to initiate the configuration lifecycle phase. This includes information such project descriptors and a project hierarchy.
class file
A plugin is a class which implements the plugin interface. When adding a plugin to a project, the plugin's class name is provided. For example, the JavaBase plugin has the class name "JavaBase". Gradle will look for the class name and its corresponding file during plugin configuration.
Configuration Object Relationship Model
To understand how configuration objects interact together and are composed to create a fully configurable Gradle Build, the configuration object relationship model demonstrates the relationship between the configuration objects introduced above.
Configuration objects interact with and are comprised of other configuration objects. For example, a project may contain many tasks, but a task can only belong to one project.